Computing devices are initialized by firmware included within the device and this firmware provides a range of software services which facilitate the boot of the operating system (OS) as well as providing a subset of these services that continue to be available after the operating system has booted. Firmware is software that has been written onto Read-Only Memory (ROM) modules including, but not limited to, ROM, PROM, EPROM, EEPROM, and Flash memory (collectively referred to hereafter as “ROM”). Among other services, the firmware is responsible for operation of the computing device until a boot process can be run which loads an operating system for the computing device into memory. Once loaded, the operating system is in charge of normal operation of the computing device although the provision of certain services after loading of the operating system may require a transition of control from the operating system back to the firmware for security and other reasons.
Unified Extensible Firmware Interface (UEFI) is a specification created by a non-profit industry body detailing a programming interface between the Operating System and the included firmware of a computing device such as, but not limited to, a Personal Computer (PC). UEFI specifications describe a set of tools by which a computing device can move in an organized fashion from the power-applied state to fully operational. The UEFI specification tells the desired result but deliberately does not specify the internal tactic of implementation. The UEFI firmware specification replaces earlier operating system (OS)/firmware interfaces previously used by the industry and commonly known as legacy BIOS (Basic Input Output System).
An option ROM driver (also referred to hereafter as “option ROM” or “driver”) is binary code to extend the BIOS or UEFI firmware to support a specific hardware device. It may include initialization, boot-related services and hardware device management. The option ROM may be included on a flash store on a plug-in card when the card is shipped or may be a driver associated with a card (or other device in the system) that is separately downloaded or otherwise communicated to the computing device. The BIOS (or UEFI Firmware) executes the option ROM when a matching plug-in adapter card (or device on the motherboard) is discovered. The option ROM is used to communicate with the associated hardware device.
Computer systems may contain one or more expansion slots such as those conforming to the Peripheral Component Interconnect (PCI) Express specification. These slots can be used to install optional input-output boards (also referred to as “expansion cards” or “option cards”) which expand the capabilities of the system. These expansion cards may include legacy BIOS components (legacy BIOS components include system BIOS which is delivered with and supports the system platform and legacy option ROMS which are incorporated into option cards and which support the initialization of the card). The UEFI specification provides the ability to create UEFI firmware for the system board as well as enabling a UEFI option ROM driver to be incorporated into the expansion card by the manufacturer. Unfortunately however, while the industry transitions towards greater support for computing devices having UEFI-compliant firmware, many currently manufactured expansion cards still frequently include only legacy option ROMs rather than the UEFI format signed option ROMs envisioned by the UEFI specification.
The lack of UEFI format signed option ROMs for a device included in a computing system with UEFI-compliant firmware becomes important when the system executes a “Secure Boot” process defined in the UEFI specification. During the conventional UEFI Secure Boot process only validated executable code is executed during a boot sequence. The conventional Secure Boot process depends upon validation of executable code against a local system security database stored in a UEFI authenticated variable. During this process there are ordinarily only two ways in which the code can be validated and therefore approved for execution during the boot process. The first way to validate executable code is that the executable code is approved if the executable has been ‘signed’ by a certificate in the system security database. The same certificate may have been used to sign a large number of ‘executables’. The second way to validate executable code is that an exact hash of the executable that had been previously stored in the system security database matches a hash of the executable being offered for execution (each hash uniquely identifies only the code upon which it was based and any alteration to that code after the storing of the hash will result in a mismatch when comparing a hash of the altered code to the hash of the original code). Once validated, the executable code may be executed during the boot sequence. Code which is not validated through either mechanism, such as a legacy option ROM whose signature has not been previously stored in the system security database, is not allowed to execute during a conventional UEFI Secure Boot.